home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The 640 MEG Shareware Studio 2
/
The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO
/
door
/
gmon_402.zip
/
GMON.DOC
< prev
next >
Wrap
Text File
|
1992-12-02
|
87KB
|
2,148 lines
╓──┐ ╓─┐┌─╖ ╓──╖ ╓┐ ╥
║ ─╥ ║ └┘ ║ ║ ║ ║└┐║
╙──╜ ╨ ╨ ╙──╜ ╨ └╜
╓─╖
╓╜ ║
╓╜ ║
╓╜ ║
╙────╫─
║
Door File Conversion, Integrator, and Organizer
By John Morris
SysOp Reference Guide
Copyright (c) 1991-1992 by John Morris
All Rights Reserved
Page 2
CONTENTS
Software License . . . . . . . . . . . . . . . . . 2
Warranty. . . . . . . . . . . . . . . . . . . . 2
Features. . . . . . . . . . . . . . . . . . . . 3
Hardware Requirements . . . . . . . . . . . . . . . 3
GMon Version History. . . . . . . . . . . . . . . . 4
Manual Conventions . . . . . . . . . . . . . . . . 6
Command Line Switches . . . . . . . . . . . . . . . 6
Function Keys . . . . . . . . . . . . . . . . . . 8
Batch Files Needed To Invoke GMon 4. . . . . . . . . . . 9
BBS Programs GMon 4.0 Will Run With. . . . . . . . . . . 10
How To Interface You Unsupported BBS To GMon. . . . . . . . 13
Getting Started With GMon 4.0. . . . . . . . . . . . . 18
GMon Editor - Main . . . . . . . . . . . . . . . . 18
Command Letters & Security Levels . . . . . . . . . . 22
Time Limits. . . . . . . . . . . . . . . . . . 23
Program Editor. . . . . . . . . . . . . . . . . 23
User Editor. . . . . . . . . . . . . . . . . . 28
Category Editor . . . . . . . . . . . . . . . . 28
GMon Text Files . . . . . . . . . . . . . . . . . 29
GMon Macros. . . . . . . . . . . . . . . . . . . 30
Upgrading To GMon 4.0 . . . . . . . . . . . . . . . 31
GMon Files . . . . . . . . . . . . . . . . . . . 32
GMon Bulletins. . . . . . . . . . . . . . . . . . 32
Program Menus . . . . . . . . . . . . . . . . . . 33
Before & After Text Files . . . . . . . . . . . . . . 33
Thanks . . . . . . . . . . . . . . . . . . . . 33
Problems? . . . . . . . . . . . . . . . . . . . 34
How To Reach Me . . . . . . . . . . . . . . . . . 34
APPENDIX A: How The Points System In GMon Works. . . . . . . 35
SOFTWARE LICENSE
GMon is released as Shareware. You may use GMon for any commercial,
or non-commercial purpose. Use it on your company, private, or school BBS.
If you have thought of another way to use GMon, feel free to use it that
way.
You may copy and distribute as many copies of the program as you like, as
long as you don't charge money for the program itself. A small fee is
allowed for copying, handling, mailing, and the diskette carrying the
copy, but this amount is not to exceed the real costs.
GMon should not be used or distributed in modified form.
If you use this program on a regular basis, you are required to register
your copy. By registering GMon, you are helping the author to continue to
provide quality software.
WARRANTY
GMon is provided as is, with no warranty of any kind, either expressed
or implied.
The only guarantee is that GMon will take up space on your disk.
Page 3
FEATURES OF GMON
o Allows the use of virtually any door program from any BBS program.
o Acts as a central door 'hub' program. All your doors can be run
from GMon eliminating the need for complex door menus.
o Many different BBS's are supported thru the following files:
DORINFOx.DEF
CALLINFO.BBS
PCBOARD.SYS
DOOR.SYS
CHAIN.TXT
LASTUSxx.DAT
EXITINFO.BBS
SFDOORS.DAT
& more!
o Converts from the above file formats to even more door file formats,
including:
all of those above &
OPENDOOR.SYS (Fast Finger Doors)
USERINFO.TXT (MG Generic doors, like Planet Busters)
DOORFILE.SR (Solar Realm Doors)
& more!
o Up to 500 doors can be set up to run from GMon at any one time.
o Full network support using SHARE.EXE for file sharing & record locking.
o Supports 'local only' operation for local use without having to load
your BBS.
o Support for up to 256 nodes. (36 under RBBS-PC)
o Contains its own ANSI driver. (ANSI.SYS does not need to be loaded)
o Support for FOSSIL communications drivers.
o Support for BPS rates to 115200 (38400 with a FOSSIL driver)
o Support for non-standard communications ports.
o Supports flow control for high speed modems.
o Contains its own carrier detection routine. (no watchdog program needed)
o Multi-tasker aware. (Desqview, DoubleDOS, & DOS/Windows/OS2 idle calls)
o Keeps track of time used.
o Time of day usage can be controlled.
o Time limits according to security level.
o 20 separate security levels/time limits can be configured.
o SysOp can chat with user.
o Bulletin support. You can have your door programs create bulletins
that can be read by GMon, eliminating a lot of game bulletins in
your BBS.
o Editor program built into main program.
o Full control over how a door runs. By COM, EXE, or BATch file.
o Macro language for text files used by GMon.
o Support for 4 different ways of naming text/color menus & bulletins.
o Controls use of non-network programs on multi-node systems.
o & MORE!
HARDWARE REQUIREMENTS
o Any IBM PC or compatible computer with at least 200K of memory.
o DOS 3.1 or above (3.3 or higher recommended)
o Approximately 300K of disk space.
Page 4
GMON VERSION HISTORY
I conceived of GMon over 4 years ago. It has gone thru many revisions,
and is now finally becoming a program I like. I wanted a small, flexible,
and fast 'monitor' program for my BBS. I orignally wanted a 70-80K
program, but GMon 4.0 weighs in at about 135K. The good part about that
is the fact that GMon can now shrink the amount of memory it uses to
an amount close to 1 or 2K when running a door. GMon is now always in
memory while a doors are being run. This allows for better door control
and eliminates the need for a bunch of batch files to run each door.
GMon started out as a central program from which I could run all my
doors, but it ended up as more of a door control program allowing me
to run nearly any door thru it.
01/10/88 - GMon 1.0
--------
First release of GMon. Written to be compatible with Bob Westcott &
Rod Bowman's Door Monitor program, with improvements in speed and size.
Also included conversion code to run PCB 11, or PCB 12 doors. GMon
knew they were PCBoard doors by the fact that a string (either PCB11
or PCB12) was in the description). Made to run under RBBS-PC only!
01/24/88 - GMon 2.0
--------
The GAMES.DOR file was completely reworked to be more flexible. Eliminated
the need for certain strings (ie. 'PCB11' or 'PCB12') in the description
to run PCBoard doors. Instead you just change the program 'type'. The
batch file used by GMon was changed from GMONPCB.BAT to GMONEXTx.BAT.
Two reasons for that, 1: to make sure the correct batch file was being
run on multi node systems, and 2: to reflect the fact that not all
doors would be PCBoard ones in the future. The user interface was
changed to look more like an RBBS command prompt, thus making the user
feel more at home (I hope!) You can now customize the menu the users
sees. The X-pert toggle command was added to switch the menu on/off.
02/28/88 - GMon 2.1
--------
Several bugs fixed. More complete info on batch files was included in
the docs. It should now run single and multi node BBS with the same
ease.
03/13/88 - GMon 2.2
--------
These were the days of the quick update huh? Fixes applied to the PCBoard
interface which includes a total rewrite of the PCBOARD.DAT files that
GMon outputs. This seems to clear up the 'error 62 at line 10040' problem
with PCB12 doors (using Door Patch). Also PCBoard mode 4 was included
which will write out a plain PCBOARD.SYS and PCBOARD.DAT file. Hopefully
this will make GMon compatible with other PCB 12 games. SysOps, hitting
F1 will tell GMon to immediately exit to DOS.. (just in case)
04/10/88 - GMon 2.3
--------
The PCBoard interface was rewritten (again) so that GMon would output
a 'fake' PCBoard USER file along with the other PCB files GMon was
already creating so that Dorpatch routines greater than 2.6 would run.
These fixes work automatically, so you don't need to anything except
add the game to the GAMES.DOR file, and they should run. A bug in the
program which caused the amount of time used to be miscalculated was
cleared up.
Also added was an improved GMon edit program call GMedit20. It includes
a NAMES.DOR editor in addition to the older GMONEDIT functions.
Page 5
02/15/89 - GMon 3.1 (3.0 only released as a beta test)
--------
Several new features added this time. Main feature? hmmm.. howsabout
a 15K smaller EXE file.. thats the main feature. Added several new
switches. You can now tell GMon to use separate GAMES.DOR files for
each node. The filename would then be GAMESx.DOR (where 'x' is the
node number). You can shorten the GMon prompt to 'GMon Command?'
eliminating the actual command letters (A,B,C.. etc.) If you have
this feature turned off, GMon will look and behave exactly as before.
GMon also has a batch mode so it can be used as a simple RBBS to
PCB11/PCB12/PCB14/GAP/WILDCAT file conversion program.
GMEdit30 has been rewritten to be used locally, or from remote! Added to
GMEdit30 is a GAMES.DOR editor. GMEdit30 can be accessed by using the
SysOp command 'E'. Be sure GMEDIT30.EXE is in the current GMon directory.
When editing the GAMES.DOR file, GMEdit may change the 'look' of your
GAMES.DOR file but does not effect the way it works in any way.
02/25/89 - GMon 3.11
--------
A maintenance update to fix a problem in the /C3 and /C4 modes which
caused an 'illegal function call' error.
09/24/89 - GMon 3.13
--------
Another maintenance update, along with a couple added interfaces. GMon
should now enforce time limits correctly in all cases. Formerly an
entry in the TIMLIMIT.DOR file which looked like:
9,45,90,,
would give the error "you must call between 0000 and 2359"
This error was fixed. Added interfaces are an OPENDOOR.SYS (Fast Fingers
Door Program), and a USERINFO.TXT (MG Generic format for games like
Planet Busters)
Also **NEW** batch file info. Some external door programs tend to -eat-
command line parameters. So if you run a multi-node system this causes
items like node numbers to get lost! The fix is in the batch file section.
MONITOR1.EXE is written in C to save on some disk space, and file xfer
size.
OH YEAH!... Almost forgot. I did some work on GMEdit30.. and fixed some
really nasty GAMES.DOR Editor errors. It is now know as GMEdit31.
1990 - GMon 3.2
--------
Given out to only a few guys.. featured FOSSIL driver support.
01/19/92 - GMon 4.0
--------
GMon was utterly rewritten. It is now in C in place of BASIC. Now
is no longer RBBS-PC specific. It should work under any BBS program,
and convert files to almost any BBS interface or door interface file.
Is now one single program, with the editor in the main program. All
file formats have changed, so GMon 4.0 is not fully compatible with the
old Door Monitor, or even older versions of GMon. _BUT_ it still works
in a similar manner. All files can be edited by the GMon editor
included in the program. Instead of exiting to DOS, or RUNning a program
as in the BASIC version, GMon will swap itself out of memory and
'spawn' to the door. The door can be a COM file, an EXE file, or a
BATch file. If it is a batch file, GMon will execute a copy of
COMMAND.COM (or whatever your DOS shell is) and have it execute the
batch file. This way GMon never actually leaves memory. This also
usually eliminates the need for batch files. Swapping takes place to either
EMS, XMS, or to disk. Specific commands lines and evironment variables
can be specified for each door! Games can still be listed by category,
Page 6
if you choose, or all together as in the older versions of GMon. A
Bulletin menu was added. This allows you to tell your door programs
to create bulletins for use by GMon. This eliminates large amounts
of game bulletins in your BBS. In other words, the users can read
the game score bulletins from the game area, instead of the BBS.
Text files (menus, bulletins) can be named in 4 different ways (to
work similarly to several different BBS programs).
05/25/92 - GMon 4.01
--------
Maintenance release. Tweaked a couple of the BBS interfaces. I still am
looking for some more differences of opinions on how handles should be worked
on systems which don't have them, and games that do. Another release to
follow shortly.
12/02/92 - GMon 4.02
--------
Maintenance Release - Updated door I/O routines. Chat mode string now
properly says SysOp & User name.
MANUAL CONVENTIONS
This manual contains the following conventions:
[option] Any information inside double square brackets is OPTIONAL.
Keep that in mind when you read this manual.
GMON 4 COMMAND LINE SWITCHES
The command line is the information following the program name at the
DOS prompt.
Command line options must ALWAYS be separated by a space! If there isn't
a space, then that command line paramter will be missed.
GMON [options]
The following options are always preceded with a '/' (forward slash) or a
'-' (minus sign)
Bxx - Tells GMon to run in Batch conversion mode. 'xx' is the
type of file to convert to. [not yet implemented in 4.0]
Cv[,ww,xx,yy,zz] Communications port information. You will not need to use
this command unless, 1: The GMon docs specifically says to
for your BBS program, or 2: You are using a non-standard
communications port. (usually COM3 or above)
v - com port you wish the program to use.
The following information is optional, and is only used
when using non-standard communications ports.
ww - Base address, in HEX format, of your UART chip.
For example: COM1 uses 0x3F8, COM2 uses 0x2F8
xx - IRQ number you wish to use in decimal format.
For example: COM1 uses 4, COM2 uses 3
yy - Base address, in HEX format of your 8259 interrupt
controller chip.
Page 7
In the IBM PC/XT or compatibles, this is ALWAYS 0x20
In the IBM AT there is a second 8259 located at the
address 0xA0
The first 8259,at address 0x20,has IRQ numbers of
0 thru 7. The second 8259 chip, found in AT class
machines at address 0xA0, contains IRQ numbers of
8 thru 15.
zz - Interrupt vector number.
For example: COM1 uses 12, COM2 uses 11.
At this point you are probably thoroughly confused! Not to
worry! There are some general rules to follow in order to
set up your non-standard com port.
If your IRQ number is in the range 0 to 7, your 8259 address
is always 0x20.
If your IRQ number is in the range 8 to 15, your 8259 address
is always 0xA0.
If your IRQ is 3, then your interrupt vector MUST be 11,
and vice versa.
If your IRQ is 4, then your interrupt vector MUST be 12,
and vice versa.
Your modem or serial port board manufacturer will supply
you with the correct IRQ and UART base address.
For Example: Your COM3 serial port is located at 0x2E0, and
your IRQ is 4. Remember, IRQ 4 is on the 8259 located at
0x20, and interrupt 12 is always associated with IRQ 4.
Your /C command line parameter would be:
/C3,0x2E0,4,0x20,12
Another example. Lets say your BBS program doesn't supply
communications port information in the information file
that GMon reads. You would then need to specify that com
port on the command line. Lets say you need com 2:
/C2
COM2 is a standardized port, so you don't need to specify
the additional port info!
E[DITOR] - If you wish to use just the editor (in local mode) use this
switch.
Fxxxx - This is the directory in which to find the BBS info file
to get info in the current user. This overrides the BBS
directory you entered in GMon Edit. 'xxxx' is the directory
in which to find the file. No trailing backslash.
G[RAPHICS] - This switch forces ANSI color on. This is used in Local-only
mode.
L[OCAL] - This forces GMon to operate in Local-Only mode. This
is how you can use GMon locally. GMon always assumes that
it is the SysOp who is on when it runs locally.
Page 8
Nxx - Where 'xx' is the current node number. Must be used to
tell GMon which node it is running under. (unless your BBS
info file contains node info) You might want to use it
anyway to make sure GMon knows which node it is running
under.
Pxxxx - This command tells GMon to use a different file to get
configuration info from, instead of GMON.DEF. You might
do this for a different set up on different nodes, or
whatever else you can think of. Usually you will not
use this command.
Sxxxx - This is used to tell GMon at which speed to operate. If the
program saw
/S19200
It would open the com port at 19,200 bps.
The S command used infrequently, and is only needed in
certain situations. If you aren't sure whether or not to use
it, don't. Most BBS interface files provide the bps rate
for GMon.
Remember, most switches never need to be used. The only switches you may
frequently use are:
/L[ocal] (local mode)
/G[raphics] (turn on ANSI mode)
/Nxx (node number)
To run GMon in local mode, you would use the command:
GMON /L
You could add a /G to that to turn on Graphics.
GMon assumes that it is running on Node 1. On multi-node systems you
need to tell GMon which node its on, you would use the /Nxx command
like so:
GMON /N3
for node 3.
For RBBS-PC users, you would still use regular RBBS node numbers, in other
words:
'1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ'
for RBBS node 11, you would use:
/NA
GMON SYSOP FUNCTION KEYS
GMon has a few function keys enabled so you can control certain
aspects of the current session.
Page 9
F1 - Pressing the F1 key will the cause GMon to immediately
terminate the current session. It will not drop carrier
on the user, but simply end the game, and return to
DOS and the batch file that ran it.
F2 - Shell to DOS. Since this is so infrequently used it isn't
set up very well. You must have COMMAND.COM in the current
directory for this to work. Type EXIT at the DOS prompt
to return to GMon.
F9 - This toggles the local display on and off. RBBS-PC and
PCBoard SysOps will be familiar with this feature. By
pressing F9 you simply change the display status of GMon
not the display status of your BBS.
F10 - This invokes the SysOp chat mode. Hit ESCape to exit back
to GMon.
PGDN & - These two keys are used to DECREASE a users time limit. PGDN
CTRL-PGDN will subtract 1 minute from the users time limit. CTRL-PGDN
will subtract 10 minutes for each press! The results are
shown to you in the lower right hand corner.
PGUP & - PGUP and CTRL-PGUP are used to INCREASE a users time limit.
CTRL-PGUP Pressing PGUP once will increase the limit by 1 minute.
Each press of CTRL-PGUP will increase time left by 10
minutes! As above, the results can be found in the lower
right-hand corner.
End of Function Key Section.
SETTING UP BATCH FILES TO RUN GMON
To run GMon you usually need to set up a small batch file. This
batch file needs to do 4 or 5 things. These are the steps:
1: Change directory to where GMon is located
2: Optional. Copy the BBS interface file to the GMon directory
3: Run GMon
4: Change directory back to your BBS
5: Re-run the BBS batch file (if needed)
Step 2 is optional, because in many cases you can tell GMon where to find
the BBS interface file in the GMon editor (or on the command line) instead
of copying it.
A sample batch file, lets call it GMON.BAT, you're running RBBS, node 2,
the DORINFO2.DEF is in the \RBBS\NODE2 dir, and you are using COM3, a
non-standard port.
CD\GMON40
GMON /N2 /C3,0x3E8,3,0x20,11 /F\RBBS\NODE2
CD\RBBS
You would need to modify this for your set-up, but you can see how simple
the batch file is.
In many cases you won't even need a command line, just 'GMON'. Multi-node
systems would just need to tell GMon which node, like so:
GMON /N4
Page 10
BBS PROGRAMS GMON WILL RUN WITH
GMon is no longer 'RBBS-PC specific'.. It will run under many different
BBS programs. When you run GMon the first time, you will be shown the
GMon editor, and there is where you will tell GMon which BBS program it
is running under. I'll give you a list of BBS programs, and what files
GMon will expect to get its information from.
RBBS-PC 15.1C & Greater (DORINFOx.DEF & MESSAGES)
In this mode, GMon will try to read the DORINFOx.DEF, and the node records
of the main message base file. When you specify that you are running GMon
under this mode, you will be shown option 'C' in the main GMEdit screen.
This command allows you to specify the _name_ of the main message base.
Commonly this file is called either MESSAGES, or MAINM.DEF. GMon will
also ask what the BBS directory is. This is where it expects to find both
the DORINFOx.DEF and main message file. If this is not the case on your
system, not to worry. If your main message file, and your DORINFOx.DEF file
are in separate directories, you will need to temporarily copy your
DORINFOx.DEF file to the same directory as your main message base. Then
specify that directory as the BBS directory. After you GMon is done running
you could then delete that temporary copy of the DORINFOx.DEF file, it is
up to you.
Why does GMon read the node records? Well, it doesn't _have_ to, but I
try to create complete file conversions, and the more info I have the
better. The DORINFOx.DEF file just doesn't contain a whole lot more than the
necessary info. The node records hold a lot more info on the current
user.
If you don't want GMon read your main message file node records, then you
can do one of two things. Don't put in any filename for the main message
file (in GMEdit), or switch to QBBS mode. The former is preferable.
Since GMon both, can read _and_ write a DORINFOx.DEF and MESSAGES file
(just the node records) it is imperative that you do not put any door
programs in your BBS directory. Well.. okay.. it isn't imperative, but
don't do it, just to be on the safe side.
RBBS-PC was the first program to create a DORINFOx.DEF file for doors.
The format of the RBBS style DORINFOx.DEF file is the one I consider the
standard (even though it is a bit flaky in some spots) GMon will also read
and write what I call an 'Odd DorInfo File', in other words ones which
don't exactly follow the RBBS standard. I'll explain more about that
below in the special DORINFO section.
PCBOARD 12.x & 14.x (PCBOARD.SYS)
In this mode GMon will read a PCBOARD.SYS file in the BBS directory you
specify. If you have a multi node system, then you probably will have
each nodes PCBOARD.SYS in different directories. If this is the case, then
specify, on the command line, the directory in which to find this nodes
copy of PCBOARD.SYS. Use the '/Fxxxx' command for this (see above in
the command line switch section) The '/F' switch overrides the default
BBS directory you enter inside the GMon editor.
If you find it easier to rename your PCBOARD.SYS files for each node
(PCBOARD1.SYS.. PCBOARD2.SYS.. etc.) and put them all in the same directory
(like some doors require) you can do this with GMon too. Tell GMon that
you are running PCB 12 or 14 (depending on your version of PCBoard) _and_
turn on the 'BBS info file has node#' switch. GMon will then look for
Page 11
a PCBOARDx.SYS (where 'x' is the node number on the cmd line) This is
not standard operation, but will work just fine.
GMon will read only the PCBOARD.SYS file in PCB mode. It will not read
your PCBOARD.DAT, or user file.
WILDCAT! 2.x (CALLINFO.BBS)
In this mode GMon will read the CALLINFO.BBS file in the directory you
specify in the GMon editor. If you have more than one directory in which
GMon may need to find the CALLINFO file, then you can specify each directory
on the command line instead using the '/Fxxxx' command line parameter.
GAP & WILDCAT! 3.x (DOOR.SYS)
In this mode GMon will read the DOOR.SYS file in the directory you specify
in the GMon editor. If you have more directory in which GMon may need to
find the DOOR.SYS file (as in a multi-node set-up), then you can specify
each directory on the command line instead using the '/Fxxxx' command line
parameter.
RA 1.x (EXITINFO.BBS & DORINFOx.DEF)
In RA mode, GMon will try to read both the DORINFO1.DEF and EXITINFO.BBS
files in the BBS directory you specify in the GMon editor. If you are
running multiple nodes, then you will have multiple directories in which
to find these two files (according to node). If this is the case, then
you will need to use the '/Fxxxx' command line parameter to tell GMon
where to find those two files for that node. Both of those files should
be in the same directory.
OPUS 1.1x (LASTUSxx.DAT)
Gmon will try to read the LASTUSxx.DAT file in the directory you specify
in the GMon editor in this mode. 'xx' is the node number (in HEX format)
and GMon will put in the node number according to the node number you
specify (in DECIMAL) on the command line. For instance, if you had a 10
node system and this copy of GMon was running on node 10, then you would
tell GMon the node was node 10 like this: 'GMON /N10' GMon would
then look for the following filename: 'LASTUS0A.DAT'
I haven't been told whether or not the LASTUSER file has changed with
OPUS 1.7.. so I am going to take a wild guess and say it hasn't changed.
Let me know if I made the wrong assumption.
SPITFIRE (SFDOORS.DAT)
GMon will look for an SFDOORS.DAT file in the BBS directory you specified.
If you have multiple SFDOORS.DAT files, then use the '/Fxxxx' command line
parameter.
WWIV (CHAIN.TXT)
In this mode, GMon will look for a CHAIN.TXT file in the BBS directory you
specify in the GMon editor. If you have multiple CHAIN.TXT files in
multiple directories, then you can override the default BBS directory
with the '/Fxxxx' command.
Page 12
GTPOWERCOMM (GTUSER.BBS)
[Not Implemented.. yet]
PHOENIX (INFO.BBS)
[Not Implemented.. yet]
QBBS (DORINFOx.DEF)
In this mode GMon will look for information in the DORINFOx.DEF file. The
DORINFO file is searched for in the path that you specified in the GMon
editor. If you have more than one path in which to find those DORINFO
files, then you will need to use the '/Fxxxx' command to tell GMon where
to locate the DORINFO file it needs.
SPECIAL CASE (DORINFO1.DEF)
I threw this one in there for doors which can only read a DORINFO1.DEF
(it appears that this is so, even though that '1' should be whatever
the node is.) GMon can also read from just a DORINFO1.DEF (no matter
what the node number is) if your BBS program creates a DORINFO1.DEF by
that filename only. And this mode _requires_ that! I don't know if
anyone would have any use for that, but it's in there anyway.
In this mode GMon will read the DORINFO1.DEF file no matter what node
number you specify. So be wary when using this mode.
OTHER BBS INTERFACE INFO
If your BBS info filename normally does not have a node number in it, but
on your BBS you rename those files to reflect the node, GMon can operate
in that fashion. If you turn on the 'BBS Info File Name Has Node #' switch
GMon will look for a filename with a node number in files that usually don't
contain one. ie. If you tell GMon you are running under Wildcat! 2.x, GMon
will normally look for CALLINFO.BBS.. but if you turn on the above switch
GMon will look for CALLINFx.BBS where 'x' is the node number.
The following files, which normally don't have node numbers in the filename,
will be converted like so (with the special switch turned on):
PCBOARD.SYS -> PCBOARDx.SYS
CALLINFO.BBS -> CALLINFx.BBS
DOOR.SYS -> DOORx.SYS
EXITINFO.BBS -> EXITINFx.BBS
SFDOORS.DAT -> SFDOORSx.DAT
GTUSER.BBS -> GTUSERx.BBS
INFO.BBS -> INFOx.BBS
'x' is the node number.
Once again, I don't know if there is much use for this option, but it fit
into the code automatically.. so I wanted to document it!
Thats it for BBS's which GMon can operate with.
Page 13
HOW TO INTERFACE YOUR UNSUPPORTED BBS TO GMON
I suggest two different methods of interfacing to GMON. Both are
simple text files. One is more complex than the other, but contains
more complete information on the user. First I'll cover the DORINFOx.DEF
standard, then the DOOR.SYS standard.
The DORINFOx.DEF file. The 'x' in the filename is always the node number.
So for a single node BBS, the file would be named:
DORINFO1.DEF
For multi-node BBS programs, the file would be named like so:
DORINFO1.DEF for node 1. DORINFO2.DEF for node 2 etc.
This file is an RBBS-PC standardized file, and there are only 36 node
numbers supported. the 36 nodes are numbered like so:
1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
So, node 10's DORINFO file would be DORINFO0.DEF, node 36's would be
DORINFOZ.DEF
GMon accepts a command line parameter to specify the current node number.
If your command line read
GMON /N8
GMON would look for DORINFO8.DEF. Get the idea?
Now we move onto the format of the file itself.
The format of the DORINFO file is as follows:
BBS Name
SysOps First Name
SysOps Last Name
Com Port
BPS Rate and Parity
RBBS Network type
Current Users First Name
Current Users Last Name
Current Users City/State
Graphics
Security Level
Minutes Left in Session
FOSSIL Driver present
Page 14
All lines are in capital letters. I'll give you two examples of what the
file typically look like:
Example 1 Example 2
THE ABANDONED LAND THE ABANDONED LAND
JOHN JOHN
MORRIS MORRIS
COM2 COM0
2400 BAUD,E,7,1 9600 BAUD,N,8,1
0 3
JOE SYSOP
BBS
RENO, NV RENO, NV
0 2
5 20
57 119
0 -1
In example 1, the remote user is at 2400 BPS, even parity, with 7 data
bits. No graphics (regular text), and RBBS is not using a FOSSIL driver.
In example 2, the local user is the SysOp. ANSI color is on, and a FOSSIL
driver is present.
There are several 'quirks' in the DORINFO standard. They are as follows.
1: A local user is online when the com port is set to COM0
Also, GMon will recognize a BPS rate of '0' as a local user, but
this is not the standard method.
2: When the SysOp is using the game, the 'Current Users First Name' is
"SYSOP" (without the quotes), and 'Current Users Last Name' is ""
a null string. (the only chars found on that line are a carriage
return/linefeed combo)
Also acceptible is setting the Users first and last name to match
the SysOps first and last name exactly, but this also in not standard.
3: Graphics are off when a 0 is found in the graphics field. RBBS-PC
uses a 1 when the user can accept IBM high bit chars, and 2 for
ANSI color. When in RBBS mode, a 2 is needed to turn on ANSI color
in GMon. When in QBBS mode, a 1 in the graphics field will turn on
ANSI color.
This difference is due to different BBS's doing slightly different
tweakage to the DORINFO standard. GMon tries its best to cope with
these differences.
4: Note the BPS Rate and Parity field. Whatever the BPS Rate and Parity
is, it must match the format shown! Here are some more examples:
300 BAUD,N,8,1
1200 BAUD,E,7,1
19200 BAUD,N,8,1
GMon will parse out the " BAUD" part of the string, and go from there.
5: GMon doesn't use all the fields in the DORINFO file. Here are the fields
GMon DOES NOT use: BBS Name, SysOps first or Last name, Network type,
and FOSSIL driver. These lines are not used, but must still be present
in one form or another.
6: Everything in the file should be in CAPS.
Page 15
7: The space seen in front of the numbers is due to the way BASIC writes
numbers to disk. They may or may not be present. Doesn't matter really.
This file is small and simple, and I like it. The only real drawback is
the limited number of nodes, and lack of complete information on the
system it is running under. But it does what it set out to do, run
doors, and it does that just fine.
The DOOR.SYS file. The DOOR.SYS file is also a text file but contains
more information about the system it is running on, and more information
on the user too.
The DOOR.SYS file always keeps the same name. It is just found in
different subdirectories for different nodes. So when you run GMon, you
need to tell it where to find the DOOR.SYS file for that node. You
use the '/Fxxxx' command to do it.
GMon uses the 52 line version of this file, which is a super-set of the
original DOOR.SYS file. If this is an inconvenience, then I'll make a
mode which will accept the old style DOOR.SYS file also.
We'll drop to the next page to explore the file format.
Page 16
The format of the file is as follows: (with some notes on exact format)
Com Port (COM1: for com port 1. COM0: is used for local user)
BPS Rate (Speed user called in at 300-38400)
Parity (7 or 8)
Node Number (1 to 99)
DTE Rate (actual com port speed to use)
Display On/Off (Y=On N=Off)
Printer On/Off (Y=On N=Off)
Page Bell On/Off (Y=On N=Off)
Caller Alarm On/Off (Y=On N=Off)
Full User Name
Users City/State
Home Phone
Data Phone
Password
Security Level
Total Times On
Last Date Called
Seconds Remaining This Call
Minutes Remaining This Call
Graphics Mode (GR = Graphics, NG = No Graphics, 7E = E,7,1)
Page Length
Xpert Mode (Y = Expert, N = Novice)
Conferences Registered In
Conference In When Opened Door
Expiration Date (mm/dd/yy)
User File Record Number
Default Xfer Protocol (C, X, Y, Z, Etc.)
Total Uploads
Total Downloads
Daily K-Bytes Downloaded
Daily Maximum K-Bytes To Download
Callers Birthday (mm/dd/yy)
Path to User File
Path to GEN Directory (?)
SysOps Name (as on BBS)
SysOps Alias
Event Time (hh:mm)
Error Correcting Modem (Y or N)
ANSI Supported By User but Not Being Used (Y or N)
Use File Locking (Y or N)
Default Color (IBM type color code.. 1 to 15)
Time Credits In Minutes (this can be positive or negative)
Last New Files Scan Date (mm/dd/yy)
Time Of This Call (hh:mm)
Time Of Last Call (hh:mm)
Maximum Daily Files Available
Files Downloaded Today
Total K-Bytes Uploaded
Total K-Bytes Downloaded
Comment On User
Doors Opened
Messages Left By User
As you can see, this file has a LOT of information in it. GMon will not
use even a half of that info. But the DOOR.SYS file is intended as a
standard for all BBS's to use. And hopefully more of them will use it
in the future. On the next page, I'll give you an example of what a
DOOR.SYS file might look like.
Page 17
On this page I'll give you an idea of what a DOOR.SYS file might look like.
COM2:
9600
8
1
19200
Y
N
N
N
Joe Bbs
Reno, NV
702 746-1364
702 746-1365
BAGEL
10
125
01/01/95
2701
45
GR
24
Y
1,2,3,4
3
01/01/96
54
Z
0
15
100
1024
12/31/60
C:\BBS
C:\GEN
John Morris
E-Male
02:00
Y
N
Y
12
-5
01/01/95
03:47
05:12
20
1
0
2314
Likes To Play TW2
176
18
Just another ordinary text file. Most of the information contained in the
file makes life easier for file transfer doors to work. (lots of file
xfer info contained in the file)
Page 18
Some notes on the DOOR.SYS file.
1. Like the DORINFO file, a local user is specified by saying COM0:
(note the different format of the com port string. The DORINFO file
uses COM0, while the DOOR.SYS file uses COM0: a colon is added.)
2. Use the DTE rate line to give the speed to open the port at.
There is a difference between the BPS rate and the DTE rate. Say your
BBS modem is locked at 19200 at all times. Some guy calls in at 2400.
The BPS rate would be 2400, but the DTE rate would be 19200.
3. GMon will use the 'seconds left in session' field to get the time
remaining.
4. GMon will use field 4 to get the node number instead of you having to
specify it on the command line.
That is pretty much the extent of it. When making the file make sure you
fill in all the info, even if it is faked! Every line has to be there so
GMon won't get out of sync with the contents of the file.
GETTING STARTED WITH GMON
GMon is simple to set-up. Simply unZIP the contents of the GMon ZIP
file into its own directory. Then run GMon with the command:
INSTALL
This batch file will provide you with a bit of info, then run GMon.
GMon will then create GMON.DEF, USERS.GMN, and PROGS.GMN. You are then
brought into the GMon editor automatically. At this point you want to
change the GMon defaults to match your system. You can edit these at
any time, but you might as well do it the first time you run it.
Add in some games using the program editor.. and..
After you have used the GMon editor, you can exit out, and create the
batch file which will run GMon. See the batch file section (above) on
how to do that.
Make GMon available to your users on your BBS, and away you go!
GMON EDITOR PROGRAM
The GMon editor is part of the main GMon program. In local mode, you use
the 'E' command to enter the editor. Once you have entered the editor
you will see a screen full of options you can edit. I'll go thru these
options one by one.
A - GMon Directory
This is set automatically by GMon when it is first run. If you need
to change this from the default, then do so here.
B - BBS Directory
This is the directory in which GMon expects to find the BBS info files
To read. If you have more than one directory containing the BBS info
files, then you can override this default BBS directory by using the
'/Fxxxx' command line parameter.
Page 19
C - RBBS Message File Name
This option is used only to specify the _name_ of the main RBBS
message base (usually MESSAGES, or MAINM.DEF). GMon will use this
name when in reading a messages file in RBBS-PC mode, and will also
use this name when writing a pseudo-messages file when the in 'RBBS'
mode for a door.
D - Bulletin Menu Name
This is the name of the menu shown to the user when they choose the
B)ulletin command. The default name is BLT. All GMon bulletins
must reside in the GMON directory at this point in time.
E - Bulletin Prefix Name
GMon bulletins are numbered. Here you give the prefix of the filename
onto which GMon will append the numbers. The default is BLT. If the
user chose to read bulletin 1, GMon would search for the filename
'BLT1' GMon will also accept separate text and color versions of
each bulletin. See the GMon text file section for more info on that.
F - Last Maintenance Run * Currently not editable.. coming soon..
This is the date and time that the maintenance program last ran. The
maintenance program serves to clean up the USERS.GMN file, so it
doesn't grow overly large.
G - Time Between Uses Of GMon * Currently not editable.. coming soon..
If you don't want users entering GMon, then going back, and then
immediately rerunning GMon, then you can tell GMon not to let that
user back on until a specified time period has occured. In other
words, the users will have to wait the period you specify before
they can re-enter GMon.
H - Maximum Days Of Inactivity
This is period of time GMon will keep an inactive user in the user
file. After this date, the user will be deleted from the USERS.GMN
file.
I - Local Foreground Color * Not currently used.
This is the color of the foreground on the local SysOp screen. Not used
when the user is in ANSI mode.
J - Local Background Color * Not currently used
This is the color of the background on the local SysOp screen. Not used
when the user is in ANSI mode.
Page 20
K - Bulletin Path
This is the path where GMon can find the bulletins it is to display.
All bulletins should be located here.
L - Keyboard Time-Out Period
This is the time in which GMon will wait for user input. Past this time
period, and the user is automatically logged off.
M - Maximum Number Of Nodes
Set this to the maximum number of nodes in your system.
N - SysOp Security Level
This is the security level used by the SysOp. Valid numbers are -32767
to 32767 (standard integer range). Default is level 10. SysOp commands
are also set to have a default level of 10.. Don't forget to change
these if your security level is different.
O - SysOps First Name
This your first name.
P - SysOps Last Name
This is your last name. (if any)
Q - System Name
This is the name of your BBS.
R - BBS Type
This is the type of BBS program that GMon is running with. See the
'BBS PROGRAMS GMON RUNS WITH' section for more info.
When editing this, you will be shown a complete list of BBS types GMon
will run with. Pick one from the list.
S - Swap Directory
When GMon runs a door program it will 'Swap' itself out of memory to
provide the maximum amount of memory to the door. If GMon can't locate
any EMS, or XMS memory to use for the swap, then it will swap itself
to disk. You can specify a ram disk here, if you have one, to make
the swap just as fast as one to EMS, or XMS. The default swap dir
is the current GMon directory.
T - Comm Input Buffer (not used when a FOSSIL driver is present)
This is the size of the communications port input buffer in bytes.
The default is 256, and you should be able to leave it set to this.
U - Comm Output Buffer (not used when a FOSSIL driver is present)
This is the size of the communications port output buffer in bytes.
The default is 256, but valid sizes are 128 to 4096. 256 to 1024
are good sizes.
Page 21
V - Program Files By Node?
The door programs GMon has access to are kept in a file called
PROGS.GMN. This file is normally used by all nodes, but if you
want separate PROGS.GMN files for each node, then turn this option
on. The file that GMon would then look for is PROGxx.GMN where
'xx' is the node in HEX format. Each node would then have to
have its own PROGxx.GMN file.
If you wish to have a special PROGS.GMN file, lets say for a
certain node, you can override the default PROGS.GMN filename
by using the '/Pxxxx' command, where 'xxxx' is the name of the
PROGS.GMN file you wish to use. See command line section for more
info.
W - Prompt has commands?
GMon has one main prompt. You can either have GMon show the valid
command letters in the prompt, or leave them out. The prompts look
like so:
<with>
[30 min. left] GMON Command <A,B,..,X>?
<without>
[30 min. left] GMON Command?
If the user has insufficient security for a certain command, it is
not included in the prompt. They are shown only commands they can use.
X - Programs By Category?
On systems with a LOT of doors, it is easier for a user to list games
by category. When they want a list of games, they are asked which
category to use, then they are shown the games that are in that
category only. You create valid category names using the '!' command
(see below) Up to 20 are allowed, and it's your job to keep track
of the categories. You will have to edit each game to tell GMon which
category it should be placed in.
Y - Allow User Aliases?
This will allow a user to use an alias when playing the games. They
will be asked for their alias when they first log on to GMon. They
cannot change it after that. Let me know if you think they should
be able to change their alias.
Z - Keep a Log?
Should GMon keep a log of what is occuring? If so, it will log info
to GMON.LOG
1 - Network Mode?
GMon requires DOS 3.1 (or greater) to run, and will almost always
open a file in shared mode even with network mode turned off! Network
mode tells GMon to lock records in those files when it makes changes.
GMon never keeps file open for more than a split second anyway, so
clashes rarely, if ever, take place.
Page 22
2 - Debug Mode?
This will tell GMon to show a little extra info on the local SysOp
screen. If there is a question as to whether GMon is reading the
right files, or getting the users name or BPS rate correct, you
can turn this on to check things out.
3 - Use .ASC & .ANS for text files?
GMon can treat text/color text files in 4 different manners! If your
BBS program normally uses .ASC to indicate a plain text file, and .ANS
to indicate an ANSI text file, then turn this switch on to make GMon
act in a similar manner to your BBS program.
This is also how TheDraw names its ASCII, and ANSI files.
Lets say a user wanted to read bulletin 1.. In this mode, a plain text
bulletin 1 would be called: BLT1.ASC A color bulletin 1 would be
called BLT1.ANS
See the text file section for more info.
4 - Max # of Bulletins
This is the maximum number of bulletins GMon will look for, or allow.
You can actually have 'fewer' than this number of bulletins, but GMon
won't recognize bulletins if they are numbered higher than this amount.
5 - Use PCBoard style names for text files.
This switch is similar in function to the ASC/ANS switch but enables
the PCBoard method of naming text/color files. The letter 'G' is
always appended to a filename if it is a color file. So..
Lets say a user wanted to read bulletin 1.. In this mode, a plain text
bulletin 1 would be called: BLT1 A color bulletin 1 would be
called BLT1G
6 - Log Files By Node?
Use this to have GMON.LOG files separatly created for each node. They
will have the filename GMONx.LOG (where 'x' is the node number). If you
have more than 1 node, and you choose _not_ to have separate log files,
the node number will be prepended to each entry.
@ - BBS Interface filename has node #?
This will make GMon look for a BBS info file with a node number in it
when it normally doesn't have a node number. See the 'BBSs GMon runs
with' section.
# - Smart Text Character
This tells GMon which character denotes smart text. Default is '%'.
7 - Edit GMon Command Letters And Security Levels.
When you enter this command you will be shown a screen with all the
available commands, what letter executes that command, and what
security level is needed to execute that command.
If you wish to change a command, enter the number of the command,
you will be asked which letter should invoke that command. If you
type [ENTER] then the letter won't be changed. You will then be
asked for the security level needed to use this command.
Page 23
Three commands are considered SysOp commands, D)elete log, E)ditor,
and L)og viewer. So set these to the security level you deem
appropriate.
8 - Edit GMon Time Limits
Here you will be shown a screen with security levels, and their
associated time limits. You can set a session time limit, a
daily time limit, and you can set a certain when the user can use
GMon. If they call out side of that time period, they aren't
allowed in! You can also associate a 'Name' with a security level.
This is for BBS programs which use security names instead of numbers.
GMon thinks in numbers, so it will convert Names to Numbers, and
vice versa. (Names of up to 20 chars are allowed. Case is important)
There are 20 time limits allowed. If your system has more than 20
valid time limits, not to worry! read on.
You should enter time limits in numerical order according to security
level. On my system I have security levels ranging from 1 to 20,
but I only use a few of those 20 security levels. My time limit
screen looks like so:
#. SecLvl Session Daily Start Finish Name
1. 1 30 45 06:00 18:00 SCREWOFF
2. 5 30 60 00:00 23:59 NORMAL
3. 6 30 75 00:00 23:59 GUESTSYSOP
4. 7 45 90 00:00 23:59 COOLDUDE
5. 8 45 90 00:00 23:59 REALLYCOOL
6. 9 45 90 00:00 23:59 DONATOR1
7. 10 45 90 00:00 23:59 DONATOR2
8. 15 45 90 00:00 23:59 ASSTSYSOP
9. 20 60 120 00:00 23:59 SYSOP
10. 32767 30 60 00:00 23:59
11. 32767 30 60 00:00 23:59
.
. (all these in here are the same)
.
20. 32767 30 60 00:00 23:59
GMon will read thru this list BACKWARDS from 20 until it finds a
security level 'less than or equal' to the current users security
level. If you're using Security 'Names' there must be an exact match.
So if it was a level 20 user, it would search 20 thru 10 without
finding a match. Number 9 is a 'equal' to the user, so the time
limits shown would be used: 60 minutes per session, 120 per day.
And they are allowed on basically all day.
What happens if the user is a level 12? It isn't listed! Well
GMon would search thru the list 20 thru 8 without finding a
match, but it would see that entry 7 fits the 'less than or equal to'
rule, and use the level 10 limits as the default.
9 - Edit Programs That GMon Can Execute
Here is where you tell GMon which programs it can execute, and what
'flavor' to make 'em.
You will be asked which program to edit, 'A' to add a pgm, 'D' to
delete a pgm, 'L' to list all current programs, 'R' to rebuild the
program file (deletes empty records, you rarely need to use this!).
Page 24
If you choose A)dd, then GMon will look for an empty record, or add
on a new record, and make a dummy filename for the program. You will
then be asked to edit that program. You will need to change the
dummy filename to the one you actually want.
When you just enter the game number, you will be shown a screen with
same options as when you add a game. Here are those options:
A - Program Name
This is the name of the program the user will see. It is also the
name of the COM, EXE, or BAT file that GMon will execute. If that
name is 'TW2' then GMon will expect to find either 'TW2.COM',
'TW2.EXE', or 'TW2.BAT' to run the game! It will look for a batch
file only if you turn the 'use batch file command' on.
The 'COM' or 'EXE' file is searched for in the 'Program Directory'
whereas the 'BAT' file is searched for in the current GMon directory.
** That is important to remember! **
B - Program Directory
This is where the program is located. This should be full drive
and path, with no trailing backslash. This can be on a different
drive than GMon! No problems there. GMon will changes drives _and_
directories when it executes a COM or EXE file.
This is also the directory where GMon will write the info files that
that program needs.
C - Program Command Line
You can specify the _exact_ command line you need to use to run
this program, up to 128 chars long. GMon will not use this command
line unless you use the 'Use Cmd Line' option. (below)
If you tell GMon to 'Use Cmd Line' but you don't have a command
line specified here, then GMon will use the command line used to
invoke GMon as the command line for the program.
The following Macros are valid in Command Lines _and_ Environments.
The 2 char combinations are converted to information based on the
current user & BBS info. (Default macro char is '%' you can change it)
%a = Full Alias Name %n = Full User Name
%b = Modem to Modem BPS Rate %N = Node Number
%B = PC to Modem BPS Rate (DTE) %o = SysOps First Name
%c = Com Port Number %O = SysOps Last Name
%C = Com Port as 'COM#' %p = Parity (N or E)
%d = Data Bits (7 or 8) %P = Pause Screen
%f = Users First Name %s = Security Level
%g = GMon Directory %S = System (BBS) Name
%G = ANSI Graphics 1=yes, 0=no %t = Seconds Left in Session
%l = User Last Name %T = Minutes Left in Session
%L = Local Mode 1=yes, 0=no
For instance, if you were running a door that only need the node
number on the command line, you would set the command line to:
%N
If it was on node 2, then the '%N' would be converted to '2' before
being sent to the program as the command line. As you can see, you
can put a whole lot more on the command line than just the node
number! This will help you run doors which expect complete user info
on the command line.
These macros can be put right along side regular text also. Page 25
D - Program Environment
You can specify an separate environment for each program! Some
doors need an environment variable to control how it works. For
instance, DoorPatch doors used to require that you put the statement
"SET DOORPCH=PCB" in your environment. Well instead of doing that
and using up some of your valuable environment space, you can tell
GMon the environment is 'DOORPCH=PCB' and do it that way. Much
simpler.
Most programs will NOT need their own environment. This is just
for those rare instances when a door will need some extra info.
If you don't specify an environment, then the program recieves
a copy of the 'parent' environment (the one GMon got..)
The Macros shown above will work equally well in the environment!
E - Program Security
This is the security level required to run this program. If the
user doesn't have a security level high enough then the program
will not even be loaded into memory, and therefore they can
use it. GMon, in fact, wouldn't even know of the programs existance,
so the user could not even hack away and get into that program.
F - Program Type
This is a similar list as to what you read in the 'BBS PROGRAMS
GMON WILL RUN WITH' section. This controls which interface file(s)
GMon will create for that door. All interface files are created in
the program directory you specified (with no exceptions).
RBBS-PC 15.1C & Greater (DORINFOx.DEF & MESSAGES)
In this mode GMon will created an RBBS-PC standard DORINFOx.DEF
file, and a 'pseudo' MESSAGES file with just a checkpoint, and
node records. The MESSAGES file name is the one you specified in
the main GMon editor screen. If no filename is given for the
main message file, then this file isn't written.
NOTE: I consider the RBBS-PC DORINFOx.DEF file the standard for
DORINFO files! The DORINFOx.DEF file created in the QBBS mode
is slightly different.
The differences are:
In RBBS mode the 'User First & Last Name' when a SysOp is on-line
is 'SYSOP' & '' (null) respectively. In QBBS mode, the first
and last name are the same as the SysOps first and last name when
the SysOp is on.
In RBBS mode a local user is specified by 'COM0' on the com port
line. RBBS sets the BPS rate to 9600 for a local user. In QBBS
mode a local user has a com port of 'COM0' and a BPS rate of 0.
In RBBS mode a '2' is required in the graphics field to turn indicate
ANSI mode. In QBBS a 1 means ANSI mode.
I also don't think QBBS mode has a FOSSIL driver indication line.
Those are the main ones. If you encounter a door which doesn't
appear to work correctly with an RBBS DORINFO file, then try
the QBBS style DORINFO file.
Page 26
I hate it when standards get hashed around like that! <g>
PCBoard 12.1 (PCBOARD.SYS, PCBOARD.DAT, USERS)
PCBoard 14.x (PCBOARD.SYS, PCBOARD.DAT, USERS)
In PCBoard 12.x mode, a PCBOARD.SYS (12.1 format), PCBOARD.DAT,
and USERS file is created in the program directory. Choose option
'Q' to write a PCBOARDx.SYS, PCBOARDx.DAT, and USERS file.
In PCBoard 14.x mode, a PCBOARD.SYS (14.x format), PCBOARD.DAT,
and USERS file is created in the program directory. Choose option
'Q' to write a PCBOARDx.SYS, PCBOARDx.DAT, and USERS file.
Wildcat! 2.x (CALLINFO.BBS)
In this mode a CALLINFO.BBS file is created in the program directory.
Choose option 'Q' to make a CALLINFx.BBS file.
GAP & Wildcat! 3.x (DOOR.SYS)
A DOOR.SYS file is created in the program directory. This DOOR.SYS
file follows the 52 line format. If this causes a problem, I'll
stick in a new mode which will created te older format DOOR.SYS file.
RA 1.x (DORINFO1.DEF & EXITINFO.BBS)
In this mode a DORINFO1.DEF _and_ an EXITINFO.BBS file are created
in the program directory.
Spitfire (SFDOORS.DAT)
In this mode an SFDOORS.DAT is created in the program directory.
if you choose option 'Q', the filename will be 'SFDOORSx.DAT'
WWIV (CHAIN.TXT)
In this mode a CHAIN.TXT file is created in the program directory.
If you choose option 'Q', the filename will be 'CHAINx.TXT'
Fast Fingers Door (OPENDOOR.SYS)
An OPENDOOR.SYS file will be created in the program directory,
enabling you to run Fast Fingers doors without a conversion program
(other than GMon)
MG Generic (USERINFO.TXT)
A USERINFO.TXT file will be created in the program directory. This
will allow doors like the ol' Planet Busters to work.
QBBS (DORINFOx.DEF)
Special Case (DORINFO1.DEF) & (DORINFOx.DEF - 3=ANSI)
This mode will create a QBBS 'style' DORINFOx.DEF file in the
program directory. See RBBS mode for details on the differences
in DORINFO files.
The 'Special Case' mode is used for doors which accept only
'DORINFO1.DEF' (ie. it doesn't expect a node number, just a '1')
The 2nd special case puts a 3 in the graphics mode portion of the
file to indicate ANSI mode.
Page 27
SRDoors (DOORFILE.SR)
Creates a DOORFILE.SR file in the program directory. Used for games
like SRE, AC6, or PC. Eliminates the need to run SRDOOR.EXE before
the game executes.
G - Program Category
If you told GMon to list games by category, then you need to specify
the category number here.
H - Program Description
Here you have 38 characters to describe the program.
I - Use Command Line?
If you turn this option on, then GMon will use the command line
specified above as the command line for the program. If you did NOT
specify a command line above, then the command line supplied to GMon
itself is used instead. If this switch is off, then no command
line is supplied to the program!
J - Use Environment?
If you turn this option on, then GMon will use the above environment
as the programs environment. If this switch is off, or there is
no environment listed above, the program is given a duplicate of
GMons environment.
K - Use Batch File?
GMon 4.0 eliminates the need for batch files. Well, in most cases,
not all. If you turn this option on, GMon will search the current
GMon directory for the program batch file, and execute it instead
of changing drives & directories and running the COM and EXE files
directly.
This is good for times when you need to do some extra things in
the batch file like copying files over, etc.
L - ANSI Mode
A lot of programs nowadays require that a user have ANSI capabilities.
Not exactly ANSI color, but also ANSI cursor movements. You can
tell GMon 3 things about this program.
1. Let the user use this door, even if they don't have ANSI mode
turned on. This is the default.
2. Don't let the user use this door, unless they have ANSI mode
turned on in GMon.
3. Let the user use the door, even though they have ANSI turned
off, and the door probably requires ANSI mode. Just give them
a warning before the door is executed.
M - Program Times Used
This is the number of times a program has been used.
Page 28
N - Program Can Only Have One User?
Some doors are not made to work in a network environment, and
recommend that you keep more than one user from using the game at
one time. If you turn this switch on, only one user will be able
to use the game at one time.
O - Null Cmd Line In Local Mode?
I put this in for Doorware which appear to run locally if there
is _no_ command line, and remotely if there is a command line.
Even if you specify 'use a cmd line' the cmd line in local mode
is null ("") with this switch turned on.
P - Is program currently being in use?
If someone on another node is using the program, this is 'ON'..
Q - Put a node # in the filename?
If you wish to change the default filename which contains no
no node number in the filename to one which has the node number
then turn this switch on. This affects PCBOARD.SYS, CALLINFO.BBS,
DOOR.SYS, EXITINFO.BBS, SFDOORS.DAT, CHAIN.TXT.
R - Doorware mode?
If this is turned on, GMon will write a TIMEOFFx.DOR when opening
the door, and reads in POINTSx.DOR after the program exits. This
allows GMon to get the points earned/lost in the door.
S - Disallow alias in door?
Aliases are not appropriate for some doors. If your turn this
switch on, then their real name is used for the door instead
of their alias (if you have chosen to allow aliases)
You will also be shown that last date & time the program was last used.
0 - Edit Users
You will be asked which user to edit, or you can enter a search string.
Once you have the user you wish to edit, you will see the user edit
screen.
A - User Name
This is the name of the user according to the BBS info file, and
is the name GMon will look for when searching for the user.
B - Alias Name
If you have the Alias option turned on, this will contain the alias
the user picked. No two users can have the same alias.. This is
for everyones protection.
C - Seconds Used Today
GMon keeps track of seconds used to keep a clear idea as to how
much time a user has used. It is very easy for a user to enter and
exit GMon in just a few seconds.
Page 29
D - Last Date & Time On
This is the last date and time a user last logged on, and is
currently not editable.
E - Expert mode
This determines whether or not the menus are displayed.
F - ANSI mode
This tells whether or not the user has ANSI mode turned on or off.
! - Edit Categories
You can have up to 20 categories. Use them in order, ie. don't have
any gaps. It is up to you to keep track of what the name and number
of each category is. You can then place games in these categories
according to number using the program editor.
GMON TEXT FILES
GMon offers four (4) different ways to differentiate between plain text
and ANSI color text files.
Two of these methods are defaults. Two defaults? Yup.. Two defaults.
The standard method of creating plain text and color text files is very
similar to the RBBS method of naming the files different for text & color.
The text version of the file is just the plain filename. For all of the
following examples I'll use the main GMon menu file called GMENU. The
plain text version is called GMENU. The color version has a C appended
to the filename, or GMENUC. If the user is in color mode, and GMon
couldn't find GMENUC, it will display GMENU to the user.
That is one default method GMon uses to differentiate text & color menus.
The other default method is to NOT create a GMENUC file, but place color
macro commands in the text file (GMENU) itself. GMon, as above, will look
for GMENUC, not find it, and display GMENU, into which you put the color
macros.
But what if the user isn't using ANSI and I put color macros into GMENU
which is supposed to be plain text? Good question. GMon will not put
in the color macros into the file if the user isn't in ANSI mode! It will
strip the color macros out! So _one_ text file can act like a plain text
and a ANSI color file! This method will only work for relatively simple
text files, but it is an option. That is the second 'default'.
To see what the color macros look like, check out the next section 'MACROS'
There are two optional methods for differentiating text & color text files,
and they can be chosen in the GMon editor. The first method is called
'Use ASC & ANS for files' In this method the GMENU file will be named
like so:
GMENU.ASC (plain text.. or ASCII)
GMENU.ANS (ANSI color)
This method is similar to ones used by some BBS programs, and is also the
default file naming procedure used by TheDraw.
Page 30
The other option method is one similar to the way PCBoard names its text
files. Instead of appending a 'C' onto the end of the filename, a 'G' is
appended. So:
GMENU (plain text)
GMENUG (ANSI color)
These options are included in GMon to make it easier for you to differentiate
between text & color files. ie. make it similar to the method you are already
using!
Things to remember. If the color version of the file can't be found, then
the plain text version is shown to the user. If that one can't be found
then no file is displayed to the user.
Macros can be put into any text file, color or plain text. Color macros
are never inserted into a file if the user is in plain text mode.
GMON MACRO COMMANDS
The default character which denotes a macro is the percent '%' sign. You can
change this default in the main editor to any char that you wish.. make
sure it is a character which isn't used often. For the examples I will
use the default macro character '%'.
These macros are basically the same ones you saw in the program editor!
(Its actually the same routine!) The following macros are converted as
shown:
%a = Full Alias Name %n = Full User Name
%b = Modem to Modem BPS Rate %N = Node Number
%B = PC to Modem BPS Rate (DTE) %o = SysOps First Name
%c = Com Port Number %O = SysOps Last Name
%C = Com Port as 'COM#' %p = Parity (N or E)
%d = Data Bits (7 or 8) %P = Pause Screen
%f = Users First Name %s = Security Level
%g = GMon Directory %S = System (BBS) Name
%G = ANSI Graphics 1=yes, 0=no %t = Seconds Left in Session
%l = User Last Name %T = Minutes Left in Session
%L = Local Mode 1=yes, 0=no
The color macros are for foreground colors only:
%1 = Bright Red %5 = Bright Magenta
%2 = Bright Green %6 = Bright Cyan
%3 = Bright Yellow %7 = Bright White
%4 = Bright Blue
You can use these macros in the text files you create for GMon. For instance
lets say 'Joe BBS' has logged into GMon, and in one of your text files you
have the line:
%n, This is the new version of GMon. I hope you like it.
This line is changed to:
Joe BBS, This is the new version of GMon, I hope you like it.
and then it is displayed to the user.
That's about it for macros, they are pretty straight forward, and I leave
it up to your imagination as to how they are used.
Use the 'P'ause screen macro at the beginning of a line.
Page 31
UPGRADING TO GMON 4.0
Upgrading from the older versions of GMon may not be a really simple
process. All of the file formats have changed, and the basic functionality
of GMon has changed. I suggest making a directory for GMon 4.0 and
unZIPping the GMon ZIP file into it. Then run INSTALL.BAT and use
the editor. Use GMon edit to add in the games, and set the switches.
The way programs are run is the biggest change. GMon no longer exists
out to a batch file to run an external door. It will execute the file
from within GMon, no matter if that command is a COM, EXE, or BAT file!
For instance, with GMon 3.x I had my Stellar Quest game set up as an
external generic RBBS door. (Type 1 in GMon 3.x) I had a batch file
called SQUEST.BAT which GMon exited and executed. This batch file looked
like so:
ECHO OFF
ECHO ┌─────────────────────┐
ECHO │ STELLAR QUEST │
ECHO └─────────────────────┘
D:
CD \DOORS\SQUEST
SQUEST %NODE% \DOORS\SQUEST RBBS
C:
CD \RBBS
GAMES %NODE%
Notice the drive change, and the command line.
Under GMon 4.0 I was able to eliminate the batch file! Here is the info
for the SQuest program under 4.0:
Program Name: SQuest
Pgm Directory: D:\DOORS\SQUEST
Pgm Cmd Line: %N \DOORS\SQUEST RBBS
Pgm Type: RBBS-PC 15.1C & up
Use Cmd Line: YES
Use Environment: NO
Use Batch File: NO
ANSI mode: ANSI must be on to run this program Page 32
When GMon 4.0 runs a program it will change drives _and_ directories before
it executes an EXE or COM file. It will then run that program with the
command line I chose (notice the %N macro to tell the program the node #)
When the program exits, GMon changes drives and directories back to the
GMon directory, and then shows the command prompt to the user.
In other words, GMon does all of the batch file commands shown without
ever exiting!
So... You will want to set up GMon 4.0 completely from scratch! and then
test it out. Then you can change your current batch file that runs GMon 3.x
over to run GMon 4.0 and see how it works.
GMON FILES
GMon uses very few files.
CHAMPS.GMN Monthly Doorware points champions
GMENU & GMENUC are the main menu files.
GMEPLG & GMEPLGC File shown to user when they use the G)oodbye command
GMHELP & GMHELPC is the help file shown to the user using 'H' or '?'
GMNEWS & GMNEWSC is the file shown to the users when they log into GMon.
PROGS.GMN is the file which contains program info.
USER.GMN is the GMon user file.
Optional files include the BLT (bulletin) files, and CATx & CATDx (category)
menus of games.
GMON BULLETINS
GMon allows you to put all door 'score' bulletins in a directory so the
users can view them from GMon! This helps simplify your setup in that
you can put all your games bulletins in the GMon area where most of your
games are run from!
You can specify the directory, and what the bulletin menu, and the bulletin
prefix filenames are.
The bulletin menu is called 'BLT' by default. It lists the current bulletins
you have available and their desciptions.
GMon bulletins are numbered. The number of the bulletin comes directly
after the 'prefix filename'. The default prefix filename is BLT, so
bulletin 1 would be 'BLT1' bulletin 22 would be BLT22.
The text and color version work just like you were shown above in the 'text
file' section. A color version of bulletin 22 would be BLT22C. If you chose
the 'ASC & ANS' option, the text version would be BLT22.ASC, and the color
version would be BLT22.ANS. Under PCBoard text mode, the files for bulletin
22 would be BLT22, and BLT22G.
You can nest the bulletin files. When the user chooses the bulletin command
they are shown the bulletin menu, but it is not shown to them again unless
they ask for the menu with the L)ist command. Therefore, your bulletin menu
could describe, lets say, 10 other bulletins which match your categories.
If you said in your bulletin menu that bulletin 1 was a list of bulletins
from your adventure game bulletins, then your bulletin 1 would describe
which numbers to type to see those bulletins. All bulletins must have a
unique number.
This method is sort of a false way of nesting bulletins. Pressing enter
Page 33
brings the user back to the GMon menu, not to the previous bulletin menu.
If they want a previous bulletin menu, they must specify the number directly
or use the L)ist command to get the main bulletin menu shown.
PROGRAM MENUS
GMon supports a default method of displaying what programs are available,
and optionally, you can create your own menus to show what programs are
available. The default methods are pretty generic looking, and you can
spruce up the display by creating CATx & CATDx program menus. If GMon
finds these files, they will be displayed instead of the default method.
For instance, the default display for 'programs without descriptions' looks
like so:
Programs available on The Abandoned Land
1. TW2 2. SQuest 3. Carib 4. King
etc.etc.
You can make a menu which displays the games like you want it to. In this
case you want a CATx file. The CATDx file takes the place of the 'programs
with descriptions' display.
These files are named according to category, CATx & CATDx where 'x' is the
category number. What if you aren't using categories? Then use CAT0,
and CATD0. This menu is also displayed when you use categories but only when
the user chooses A)ll categories. ie. Category '0' is all categories.
If you are using categories, then the category files are named according
to the categories you made.
Just remember:
CATx -- Where 'x' is the category (0=all) and this file has no descriptions.
CATDx -- Where 'x' is the category (0=all) this file has descriptions.
The text & color file naming conventions work here also. CAT0 is the
all category text file, CAT0C is the all category ANSI file. Etc.
BEFORE & AFTER TEXT FILES
GMon allows you to create text files to be shown to the user before and/or
after the program is run. The file shown to the user is called BEFORE,
the file afterwards is called AFTER. These files are found in the same
directory as the game. These files are shown only if they exist. These
files also conform to the GMon text/color text file conventions. For
instance, the default color versions of these files would be BEFOREC, and
AFTERC
THANKS
I would like to thank all of the guys who have helped me improve GMon
throughout the last 4 1/2 years.
Roger Reesor - Who helped me figure out exactly how those original
Doorware programs did their thing.. (and boy did they
work in wierd ways!)
Mike Hammer - Who made some mods to get GMon running on pre-15.1C
RBBS's (The versions that didn't make a DORINFO file)
Darrin Calcutt - This wacky canuck is a good friend, and supplied some
mods to improve the conversion section of GMon. I haven't
heard from him in awhile, I hope he is doing okay.
Page 34
Vanessa Kimble - Who provided the inspiration to get me off my butt and
get GMon 4.0 off the spiral notepad, and into code.
Mitchell Anstine - Who ran a hell of a lot of doors under GMon in the
early days, and really put it to the test.
The whole RBBS-PC Beta Gang.. Don Smith, Mike Davis, Rod Bowman, & all
the rest!
The Guys who registered earlier versions of GMon.
I can't possibly remember all of you. But Thanks!
HAVING PROBLEMS WITH GMON??
First of all, don't ever assume that I know about every bug.
_Always_ assume I DON'T know about ANY bugs.
Its better to inform me of a bug I may know about, than not to report it
at all!
When you discover a bug, please try and get a capture file which shows the
bug in action. As someone anonymous once said:
"Gather enough information, and the solution will be obvious"
I can't stress the importance of that enough. I also will need to know the
release number, the BBS program you're running, and a complete description
of the problem.
See the next section on how to reach me to report bugs, or incompatabilities.
PROGRAM SUPPORT / HOW TO REACH ME
I support this program to the best of my ability. There are several different
ways of contacting me.
Mail:
John Morris
1718 Woodhaven Ln.
Sparks, NV 89434
Netmail:
RBBS-Net 8:919/1 or 2 -or- Fidonet 1:213/760 or 761
BBS:
The Abandoned Land
(702) 359-1138
(702) 359-0629
Voice:
(702) 359-1303
If I'm not at home, and you have a bug report, you can leave a message about
the bug on my answering machine.
As you may hear on my answering machines message, I don't get a chance to
return many phone calls.. maybe 1 in 100.. thats it. I wish I could
return more of them, but this program is just a hobby at the moment, and
I have lots of other things I need to do. Its mainly a lack of time. I always
return mail left to me on my BBS. So if you must have a reply, e-mail me
on The Abandoned Land.
Page 35
APPENDIX A
HOW THE POINTS SYSTEM IN GMON WORKS
You can tell GMon that a door will return points to GMon by turning on the
Doorware switch in the program editor. When this mode is on, GMon will
write a TIMEOFFx.DOR in the program directory (along with the usual BBS
interface files) When the door program exits, GMon will read a POINTSx.DOR
to determine how many points were won or lost.
The TIMEOFF file is named like so:
On single node systems the file is called TIMEOFF0.DOR.. If the BBS is
multinode, then the 'x' is the node number. On node 1 it would be
TIMEOFF1.DOR.. node 3 would be TIMEOFF3.DOR.. etc.
The TIMEOFF file is a plain text file with 8 lines. The format is as
follows:
Time, In Seconds After Midnight, When User Session Limit Ends
User Number In GMon (not used by GMon 4.0.. always set to 1)
Current User Points
Minutes Left In Session (or so GMon 4.0 thinks..)
Nulls (-1=TRUE 0=FALSE, GMon 4.0 always sets this to 0)
ANSI Graphics Mode (0 = text.. -1 = ANSI)
GMon Subdirectory (with trailing backslash)
Sound on or off (Y or N)
On the next page I'll show you what a typical TIMEOFFx.DOR looks like:
A typical TIMEOFFx.DOR looks like:
76134
1
1500
30
0
-1
C:\GMON40\
N
Thats about it.. GMon is basically concerned with the POINTS field of
the file..(line 3) and for door authors, thats what you should look for.
It contains the current number of points that the user has. You can use
this in gambling games.. or just about anything. It really adds an
incentive to use the doors.
When the door exits it should write a POINTSx.DOR file (in its own directory)
which will tell GMon how many points the user won or lost.
The POINTS file is named like so:
On single node systems the file is called POINTS0.DOR.. If the BBS is
multinode, then the 'x' is the node number. On node 1 it would be
POINTS1.DOR.. node 3 would be POINTS3.DOR.. etc.
Page 67
The POINTS file is a text file with 2 lines, like so:
Time, In Seconds After Midnight, When This File Was Created
Points Won (positive #) or lost (negative #)
which might look like:
12365
-512
(user lost 512 points..)
GMon ignores the first line, and _adds_ the number in the second line to the
users current point total. If the users point total is 'below' zero, then
the users point total is set to 0.
The users points are saved in a long integer which give possible point
totals in the 0 to 2,100,000,000 range.. (give or take a few mill)
DOOR GAME AUTHORS!
I encourage door authors to use the 'Doorware' mode in their games. This
version of GMon should tie things together pretty well, and since GMon 4.0's
Doorware mode isn't specific to any BBS type, even PCBoard, or RA, or
Wildcat! games could use this system. Just have your program look for a
TIMEOFFx.DOR file in your programs directory, and if it is there, have
your program create a POINTSx.DOR for GMon to use in return!
This points system has been around 5 1/2 (as of this writing) and really
encourages use of doors.
[END OF GMON.DOC]